Jeremie Bresson

SimpleConfigurator 'bundles.info' file

Wed, 9 Feb 2022 00:00:00 +0100

Any Eclipse RCP Client applications is a set of OSGi bundles started inside an Equinox framework.

The list of bundles that are started and the order is often controlled by the SimpleConfigurator and its bundles.info file.

The bundles.info file is located inside the configuration folder of the Eclipse RCP application.

For Mac OS, it is located inside the *.app file (use the context menu "Show Package Contents" to open it):

MyApp.app
└── Contents
    └── Eclipse
        └── configuration
            └── org.eclipse.equinox.simpleconfigurator
                └── bundles.info

For windows or linux it is next to the *.exe file or bin file:

MyApp
├── myapp.exe
└── configuration
    └── org.eclipse.equinox.simpleconfigurator
        └── bundles.info

The file describes the list of bundles that will be started. It is more or less a CSV file, that looks like this:

#encoding=UTF-8
#version=1
org.eclipse.equinox.app,1.5.100.v20210212-1143,plugins/org.eclipse.equinox.app_1.5.100.v20210212-1143.jar,4,false
org.eclipse.equinox.common,3.14.100.v20210212-1143,plugins/org.eclipse.equinox.common_3.14.100.v20210212-1143.jar,2,true

For each bundle, the bundles.info file contains one line with this information:

symbolic name
version
location
start level
marked as started

The bundles are alphabetically sorted inside a bundles.info file. This make the comparison between two files easy.

The code that is parsing those files can be found in SimpleConfiguratorUtils.java:

SimpleConfiguratorUtils#readConfiguration(InputStream, URI)
And for one line: SimpleConfiguratorUtils#parseBundleInfoLine(String, URI)

This can be useful to investigate Eclipse RCP startup issues.

OSGi and javax.inject

Wed, 27 Jan 2021 00:00:00 +0100

An OSGi bundle that exports the javax.inject package.

Since a couple of years, the Eclipse platform jars are published on maven central with metadata that allows the consumption in a traditional maven project (no Eclipse Tycho required).

This article is my feedback after having experimented with PDE (the Plug-in Development Environment project).

The problem

The goal is to compile and execute code that requires this OSGi bundle from maven-central:

<dependency>
  <groupId>org.eclipse.pde</groupId>
  <artifactId>org.eclipse.pde.core</artifactId>
  <version>3.13.200</version>
</dependency>

I am using a regular maven project (with the bnd plugins to manage the OSGi related tasks). I do not have Eclipse Tycho, so maven do not have access to any P2 Update Site.

Amongst all dependencies of PDE, there is org.eclipse.e4.core.contexts and org.eclipse.e4.core.services. Those two bundles requires:

Import-Package: javax.inject;version="1.0.0",

Source: here and here.

So we need a bundle exporting this package, otherwise the requirements are not fulfilled and I get this error:

[ERROR] Resolution failed. Capabilities satisfying the following requirements could not be found:
    [<<INITIAL>>]
      ⇒ osgi.identity: (osgi.identity=org.eclipse.pde.core)
          ⇒ [org.eclipse.pde.core version=3.13.200.v20191202-2135]
              ⇒ osgi.wiring.bundle: (&(osgi.wiring.bundle=org.eclipse.e4.core.services)(bundle-version>=2.0.0)(!(bundle-version>=3.0.0)))
                  ⇒ [org.eclipse.e4.core.services version=2.2.100.v20191122-2104]
                      ⇒ osgi.wiring.package: (&(osgi.wiring.package=javax.inject)(version>=1.0.0))
    [org.eclipse.e4.core.contexts version=1.8.300.v20191017-1404]
      ⇒ osgi.wiring.package: (&(osgi.wiring.package=javax.inject)(version>=1.0.0))

In the P2 world

The bundle javax.inject version 1.0.0 is available in the Eclipse Orbit repositories.

In the maven world

The official dependency

The dependency used by most of the other libraries:

<dependency>
  <groupId>javax.inject</groupId>
  <artifactId>javax.inject</artifactId>
  <version>1</version>
</dependency>

This library does not contain any OSGi metadata in the published MANIFEST.MF.

See the corresponding open issue.

Tom Schindl’s solution

The jar from Eclipse Orbit is available at:

<dependency>
  <groupId>at.bestsolution.efxclipse.eclipse</groupId>
  <artifactId>javax.inject</artifactId>
  <version>1.0.0</version>
</dependency>

But this is not on maven central. You will need to add following repository to your pom.xml:

<repositories>
  <repository>
    <id>bestsolution</id>
    <url>http://maven.bestsolution.at/efxclipse-releases/</url>
  </repository>
</repositories>

On maven central

This question on stackoverflow gives some inputs and suggests:

From the Apache ServiceMix project:

<dependency>
  <groupId>org.apache.servicemix.bundles</groupId>
  <artifactId>org.apache.servicemix.bundles.javax-inject</artifactId>
  <version>1_3</version>
</dependency>

page on maven search

From the GlassFish project.

<dependency>
  <groupId>org.glassfish.hk2.external</groupId>
  <artifactId>javax.inject</artifactId>
  <version>2.5.0-b62</version>
</dependency>

page on maven search

After analyzing other candidates in list where artifactId == "javax.inject", there is also this one from the Lucee project:

<dependency>
  <groupId>org.lucee</groupId>
  <artifactId>javax.inject</artifactId>
  <version>1.0.0</version>
</dependency>

page on maven search

And on twitter Raymond Augé suggested the Apache geronimo project.

<dependency>
  <groupId>org.apache.geronimo.specs</groupId>
  <artifactId>geronimo-atinject_1.0_spec</artifactId>
  <version>1.2</version>
</dependency>

page on maven search

Make your choice.

JDT without Eclipse

Fri, 17 Jan 2020 00:00:00 +0100

The JDT (Java Development Tools) is an important part of Eclipse IDE but it can also be used without Eclipse.

For example the Spring Tools 4, which is nowadays a cross-platform tool (Visual Studio Code, Eclipse IDE, …), is highly using the JDT behind the scene. If you would like to know more, I recommend you this podcast episode: Spring Tools lead Martin Lippert

A second known example is the Java Formatter that is also part of the JDT. Since a long time there are maven and gradle plugins that performs the same formatting as Eclipse IDE but as part of the build (often with the possibly to break the build when the code is wrongly formatted).

Reusing the JDT has been made easier since 2017 when it was decided to publish each release and its dependencies on maven central (with following groupId: org.eclipse.jdt, org.eclipse.platform). Stephan Herrmann did a lot of work to achieve this goal. I blogged about this: Use the Eclipse Java Development Tools in a Java SE application and I have pushed a simple example the Java Formatter is used in a simple main(String[]) method built by a classic minimal Maven project: java-formatter.

Workspace or not?

When using the JDT in an headless application, two cases needs to be distinguished:

Some features (the parser, the formatter…) can be used in a simple Java main method.
Other features (search index, AST rewriter…) require a workspace. This imply that the code run inside an OSGi runtime.

To illustrate this aspect, I took some of the examples provided by the site www.programcreek.com in the blog post series Eclipse JDT Tutorials and I adapted them so that each code snippet can be executed inside a JUnit test. This is the Programcreek examples project.

I have split the unit-tests into two projects:

programcreek-standalone for the one that do not require OSGi. The maven project is really simple (using the default convention everywhere)
programcreek-osgi for the one that must run inside an OSGi runtime. The bnd maven plugins are configured in the pom.xml to take care of the OSGi stuff.

If you run the test with Maven, it will work out-of-the box.

If you would like to run them inside an IDE, you should use one that starts OSGi when executing the tests (in the same way the maven build is doing it). To get a bnd aware IDE, you can use Eclipse IDE for Java Developers with the additional plugin Bndtools installed, but there are other possibilities.

Source code can be found on GitHub: programcreek-examples

Building and running Equinox with maven without Tycho

Mon, 13 Jan 2020 00:00:00 +0100

Eclipse Tycho is a great way to let maven build PDE based projects. But the Plug-in Development Environment (PDE) model is not the only way to work with OSGi.

In particular, since 2 or 3 years the Eclipse Platform jars (including the Equinox jars) are regularly published on Maven Central (check the artifacts having org.eclipse.platform as groupId).

I was looking for an alternative to P2 and to the target-platform mechanism.

Bnd and Bndtools are always mentioned as potential alternative to PDE (I attended several talks discussing this at EclipseCon 2018: Migrating from PDE to Bndtools in Practice, From Zero to a Professional OSGi Project in Minutes). So I decided to explore this path.

This StackOverflow question catches my attention: How to start with OSGi. I had a close look at the answer provided by Peter Kriens (the founder of the Bnd and Bndtools projects), where he discusses the different possible setup:

Maven Only
Gradle Only
Eclipse, M2E, Maven, and Bndtools
Eclipse, Bndtools, Gradle

Even in the "Maven Only" or "Gradle Only" setups, the proposed solution relies on plugins using bnd under the hood.

My project is quite simple, the dependencies are already on maven central. I will not have a complex use-case with multiple versions of the same library or with platform dependent artifacts. So fetching the dependencies with maven is sufficient.

I decided to try the "Maven Only" model.

I was not sure to understand how to use the different bnd maven plugins: bnd-maven-plugin, bnd-indexer-maven-plugin, bnd-testing-maven-plugin, bnd-export-maven-plugin …

Luckily I found the slides of the Bndtools and Maven: A Brave New World workshop (given at EclipseCon 2017) and the corresponding git repository: osgi-community-event2017.

The corresponding effective-osgi maven archetypes used during the workshop are still working well. I could follow the step-by-step guide (in the readme of the maven archetypes project). I got everything working as described and I could find enough explanations about the generated projects. I think I understood what I did and this is very important when you start.

After some cleanup and a switch from Apache Felix to Eclipse Equinox, I got my running setup and I answered my question: "How to start with OSGi without PDE and Tycho".

The corresponding code is in this folder: effectiveosgi-example.

Edit an OpenAPI specification in Eclipse IDE

Fri, 8 Jun 2018 00:00:00 +0200

I am working a lot on the OpenAPI Generator project these days. This means that I need to edit OpenAPI Specification files a lot. A specification file is a *.yaml file that describes a REST API.

In Eclipse IDE I have installed the KaiZen OpenAPI Editor plugin. This is an Xtext editor that provides everything that you need to be efficient with your OpenAPI specification: outline, code completion, jumps for references, renaming support…

It can be installed from the Eclipse Marketplace.

If you use the Eclipse Installer (also called Oomph), you can add this xml snippet to your installation.setup file:

Listing 1. Oomph snippet to install the KaiZen OpenAPI Editor

<?xml version="1.0" encoding="UTF-8"?>
<setup.p2:P2Task
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:setup.p2="http://www.eclipse.org/oomph/setup/p2/1.0">
  <requirement
      name="com.reprezen.swagedit.feature.feature.group"/>
  <repository
      url="http://products.reprezen.com/swagedit/latest/"/>
</setup.p2:P2Task>

It is free and open-source (EPL). Enjoy.

Starting a new open-source project

Tue, 15 May 2018 00:00:00 +0200

Working on open-source is a skill…

Three month ago I started to use and to contribute swagger-codegen. It feelt natural to fix and to add the stuff I needed there.

Then I received an invitation from a group of people that had started a fork of the project. Without going into the details, I think that each member had its own reasons to work on this fork. We wrote a summary in the project Q&A.

Image 1. OpenAPI Generator logo proposition by @jimschubert

The last days were really exiting, we have started the openapi-generator project officially. We have now a GitHub repository: OpenAPITools/openapi-generator The first feedback arrives. We have pushed our first SNAPSHOT artifacts on sonatype central repository. We are close to our first release…

Running an open-source project

I realised during this experiment that participating in an open-source project and running it is really a skill. Some people have it, they are directly alined, they understand what they need to do. Other do not understand how it works.

I have learned it from talented people. All developers involved with projects hosted at the Eclipse Foundation and contributors of the Asciidoctor project have shown me the way. They were excellent teachers.

What is next for OpenAPI Generator?

Starting an open source project is not only about code. Communication and marketing are also important. I hope we will manage build a community of user around our project. This is the best way to find potential contributors.

About OpenAPI Generator:

If you wonder what the project is about, here my short definition:

An OpenAPI Specification (OAS) is a great way to describe API in a standardised, machine readable and programming language-agnostic manner. OpenAPI Generator is an engine to generate documentation, API clients and server stubs in different languages for a given OpenAPI Specification.

Use the eclipse-settings-maven-plugin to synchronize prefs files across projects

Mon, 5 Feb 2018 00:00:00 +0100

The question « Should the meta files related to an IDE be committed in the git repository? » is a never-ending fight. According to Aurelien Pupier, the answer to this question is YES (Talk from 2015 - slides and video). I totally agree with him, because settings files like org.eclipse.core.resources.prefs, org.eclipse.jdt.core.prefs, org.eclipse.jdt.ui.prefs or org.eclipse.m2e.core.prefs can contain valuable configuration information that will be shared between all Eclipse IDE users working on the project: code formatting rules, save actions, automated code cleanup tasks, compiler settings…

Even today a lot of people still prefer not to have the IDE metadata files in their git Repository. This means that every coworker needs to configure his IDE and more important everybody needs to keep the configuration in sync with the team over the time.

In both cases (having the settings files in your repo or not), the eclipse-settings-maven-plugin can be interesting for you. The idea is to use maven in order to replicate the same prefs files across multiple maven modules. This way you can distribute the prefs file if they are missing in the git repository. An other use case is the distribution accros multiple teams (for example at organization level).

The source for the settings file is a simple maven artifact located in a maven repository. With a single maven command, you can synchronize the prefs files.

If you wants to see how the setup looks like, you can refer to my sync-eclipse-settings-example page and the associated GitHub project. I have updated it in order to use the latest version published last week by my former colleagues at BSI Business Systems Integration AG.

Asciidoctor: watch you build log

Sun, 25 Jun 2017 00:00:00 +0200

Last thursday at Voxxed Days Luxembourg I had the opportunity to speak about asciidoctor in my talk (Documentation as code: contrôler la qualité ! - slides - video). Voxxed Days conferences are similar to Devoxx, but smaller (only one day). It was the second edition of Voxxed Days Luxembourg and the conference is really great (perfect organization, pleasant ambience, nice people and interesting conversations).

Back to my talk, I want to provide more details about a point I have presented: how to monitor your asciidoctor build logs with jenkins.

During the build, asciidoctor tells you when something is unexpected. Let me give you a real example: In the eclipse scout documentation, you have a lot of code snippets with callouts to mark certain lines.

Figure 1. Eclipse scout documentation extract

In order to do this, you need to define the callout in your source code and add the explanation after the code snippet as presented in Listing 1.

Listing 1. Callout example

[source,adoc]
.Initial implementation of class OrganizationTablePage.
----
(..)
    return TEXTS.get("Organizations"); // <1>
(..)
----
<1> Make sure to add a translated text entry for "Organizations" using the Scout NLS tooling

If there is a mismatch between the two elements, you will get a warning in your logs:

[INFO]
[INFO] --- asciidoctor-maven-plugin:1.5.5:process-asciidoc (book_scout_intro-to-html) @ scout_beginners_guide ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] ignoreDelta true
[INFO] Copying 0 resource
asciidoctor: WARNING: _TutorialStep2.adoc: line 247: no callouts refer to list item 1 beginners_guide/src/docs/beginners-guide.adoc
[INFO]

If you are using Jenkins as continuous integration server, the warnings plugin helps you to find those lines in your log. It also keeps a record of them, in order to track the evolution over the time.

Here is how you can configure the plugin in the admin view in order to detect the asciidoctor lines:

Listing 2. Regular expression:

asciidoctor: (WARNING|ERROR): ([^:]+): line ([0-9]+): (.*)

Listing 3. Mapping Script:

import hudson.plugins.warnings.parser.Warning

String category = matcher.group(1)
String fileName = matcher.group(2)
String lineNumber = matcher.group(3)
String message = matcher.group(4)

return new Warning(fileName, Integer.parseInt(lineNumber), "Dynamic Parser", category, message);

Then in your build definition you need to add a post-build step:

Now you are informed when something goes wrong in your documentation. By the way there is the idea that Asciidoctor could produce a report containing all the warnings and errors that are discovered during the build. They could be collected in a xml or json file. For the moment issue #44 is still open.

You can have a look at the slides on SlideShare or at the recorded video on YouTube (in french).

PS: I have already proposed a talk for EclipseCon Europe 2017. I hope I will get a slot to be able to present more aspects of the "documentation as code" pattern.

Mylyn Wikitext is available on maven central

Sun, 26 Mar 2017 00:00:00 +0100

As announced in my previous blog post, important refactorings are going in the mylyn wikitext project. One of the first goals is achieved: the jars are now available on maven central (see also Mylyn WikiText on Maven Central by David Green). Have a look at the org.eclipse.mylyn.docs group in a maven central viewer (right now the newest version is 3.0.6).

Wikitext provides the capability to transform from one language to another. I have already blogged about the possibility to convert to AsciiDoc from Eclipse IDE (new feature introduced with Oxygen M4).

Let demonstrates how you can convert from MediaWiki to AsciiDoc, directly in a small Java program. It is just a few lines of code in a simple main class.

In the Example the content of the Scout/Contribution page taken from the Eclipse wiki will be converted into an AsciiDoc File: scout_contribution.adoc. The code is straight forward:

Listing 1. Example main class

import java.io.File;
import java.io.StringWriter;
import java.net.URL;

import org.eclipse.mylyn.wikitext.asciidoc.internal.AsciiDocDocumentBuilder;
import org.eclipse.mylyn.wikitext.mediawiki.MediaWikiLanguage;
import org.eclipse.mylyn.wikitext.parser.DocumentBuilder;
import org.eclipse.mylyn.wikitext.parser.MarkupParser;

import com.google.common.base.Charsets;
import com.google.common.io.Files;
import com.google.common.io.Resources;

public class MediaWikiToAdocExample {

  public static void main(String[] args) throws Exception {
    String url = "http://wiki.eclipse.org/index.php?title=Scout/Contribution&action=raw&templates=expand";
    String input = Resources.toString(new URL(url), Charsets.UTF_8);

    MediaWikiLanguage markupLanguage = new MediaWikiLanguage();
    markupLanguage.setInternalLinkPattern("https://wiki.eclipse.org/index.php?title={0}");
    MarkupParser parser = new MarkupParser(markupLanguage);

    StringWriter writer = new StringWriter();
    DocumentBuilder builder = new AsciiDocDocumentBuilder(writer);
    parser.setBuilder(builder);
    parser.parse(input);

    String output = "= Eclipse Scout - Contribution\n\n";
    output += writer.toString();
    Files.write(output, new File("scout_contribution.adoc"), Charsets.UTF_8);
  }
}

On your classpath, you will need some of the wikitext jars and google guava. The pom.xml File for Maven looks like this:

Listing 2. pom.xml for the Example

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>wikitext.examples</groupId>
    <artifactId>mediawiki-to-adoc</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>org.eclipse.mylyn.docs</groupId>
            <artifactId>org.eclipse.mylyn.wikitext</artifactId>
            <version>3.0.6</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.mylyn.docs</groupId>
            <artifactId>org.eclipse.mylyn.wikitext.mediawiki</artifactId>
            <version>3.0.6</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.mylyn.docs</groupId>
            <artifactId>org.eclipse.mylyn.wikitext.asciidoc</artifactId>
            <version>3.0.6</version>
        </dependency>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>21.0</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.6.0</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Here is a side by side comparison of the wiki page and of a preview of scout_contribution.adoc:

If you look very closely at this example, you might notice some issues during the conversion process. I have reported them in Bug 508262.

If you are interessted by the Mylyn Wikitext project, you can follow @WikiText on twitter. You can ask questions on StackOverflow using the mylyn-wikitext tag. Are you looking for more usage examples of Mylyn Wikitext? Have a look at greensopinion/wikitext-examples on GitHub. David Green has prepared additional use cases there.

Mylyn Docs Wikitext: changes with Version 3.0.0

Thu, 2 Feb 2017 00:00:00 +0100

David Green has proposed to do a lot of changes to Mylyn Docs Wikitext. The "core" plugins will now be plain java/maven artifacts. The expected benefits are:

easier to build/release Mylyn Docs (or at least Mylyn WikiText) separately from Mylyn
easier to consume Mylyn WikiText core bundles (e.g. as plain jars, with normal poms)
easier to contribute (e.g. without knowledge of OSGi or PDE)
better structured code/tests (e.g. using normal Maven project layout)
faster cycle time (e.g. easier to verify code changes, faster builds)

Another side goal is to be present on maven central as soon as possible.

These structural modifications require changing the version to 3.0.0-SNAPSHOT and this is the occasion to review what we are publishing and how (update sites, features, p2 repository, bundle names, package names, …). If you are using wikitext as part of your build (to build the eclipse help for example) or as part of another tool, be aware that this is a breaking change. Your feedback is welcomed on Bug 511120. You can also follow the discussion on the mylyn-docs-dev mailing list.

Here is one example: we might drop the standalone distribution of wikitext (jars available in a zip) that is currently available on the Mylyn download page.

If you are using it, please notify us on Bugzilla.

Ressource filter at project level in Eclipse IDE

Fri, 27 Jan 2017 00:00:00 +0100

If you follow the maven convention in multi-modules maven project, your directory structure will looks like this:

\---parent
    |   .project
    |   pom.xml
    |
    +---project1
    |   |   .classpath
    |   |   .project
    |   |   pom.xml
    |   |
    |   \---src/main/java
    |       \---...
    |
    \---project2
        |   .classpath
        |   .project
        |   pom.xml
        |
        \---src/main/java
            \---...

When the projects are imported in Eclipse IDE, the parent project looks not nice in the Package Explorer. The child modules project1 and project2 appear twice: as sub-folder of the parent project and as separated java project. In my opinion this is not really user-friendly.

A solution was suggested by Ed Merks: in the parent project, the child folders can be filtered. Use the Ressource Filters at project level. Select the Properties context menu on the parent project and select "Ressource Filters" under "Ressource" in the tree. Click on the Add Filter… button. In the Dialog configure your filter to exclude all folders with a name that matches *.

The configuration should look like this:

If you have a look at the xml content in the .project file of the parent project, you should see something like this:

	<filteredResources>
		<filter>
			<id>1485436062166</id>
			<name></name>
			<type>10</type>
			<matcher>
				<id>org.eclipse.ui.ide.multiFilter</id>
				<arguments>1.0-name-matches-false-false-*</arguments>
			</matcher>
		</filter>
	</filteredResources>

With this new project configuration, the Package Explorer now hides its child folders. This means that you no longer see the modules project1 and project2 in the parent project:

I hope this will helps projects that have similar needs.

There is also an easier way to display this standard maven structure in Eclipse IDE: use the Project Explorer instead of the Package Explorer.

With the menu item Projects Presentation ▸ Hierarchical the display behavior in the Project Explorer can be modified.

With this new configuration, the maven structure is reflected in the IDE:

This works even with the resource filter configuration approach presented in this blog post.

Use the Eclipse Java Development Tools in a Java SE application

Tue, 10 Jan 2017 00:00:00 +0100

Stephan Herrmann has announced that some libraries of the Eclipse Neon.2 release are now available on maven central.

It is now easy to reuse the piece of Eclipse outside any Eclipse based application. Let me share with you this simple example: use the java code formatter of Eclipse JDT in a simple java main class.

Step 1: create a very simple maven project. You will need org.eclipse.jdt.core as dependency.

Listing 1. Example pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>example</groupId>
  <artifactId>java-formatter</artifactId>
  <version>1.0.0-SNAPSHOT</version>

  <dependencies>
    <dependency>
      <groupId>org.eclipse.jdt</groupId>
      <artifactId>org.eclipse.jdt.core</artifactId>
      <version>3.12.2</version>
    </dependency>
  </dependencies>
</project>

Step 2: write a java class with a main method.

Listing 2. Example main class

import java.util.Properties;

import org.eclipse.jdt.core.JavaCore;
import org.eclipse.jdt.core.ToolFactory;
import org.eclipse.jdt.core.formatter.CodeFormatter;
import org.eclipse.jdt.internal.compiler.impl.CompilerOptions;
import org.eclipse.jface.text.BadLocationException;
import org.eclipse.jface.text.Document;
import org.eclipse.jface.text.IDocument;
import org.eclipse.text.edits.TextEdit;

public class MainFormatter {

  public static void main(String[] args) {
    String result;

    String javaCode = "public class MyClass{ "
                        + "public static void main(String[] args) { "
                        + "System.out.println(\"Hello World\");"
                        + " }"
                        + " }";

    Properties prefs = new Properties();
    prefs.setProperty(JavaCore.COMPILER_SOURCE, CompilerOptions.VERSION_1_8);
    prefs.setProperty(JavaCore.COMPILER_COMPLIANCE, CompilerOptions.VERSION_1_8);
    prefs.setProperty(JavaCore.COMPILER_CODEGEN_TARGET_PLATFORM, CompilerOptions.VERSION_1_8);

    CodeFormatter codeFormatter = ToolFactory.createCodeFormatter(prefs);
    IDocument doc = new Document(javaCode);
    try {
      TextEdit edit = codeFormatter.format(CodeFormatter.K_COMPILATION_UNIT | CodeFormatter.F_INCLUDE_COMMENTS,
                                             javaCode, 0, javaCode.length(), 0, null);
      if (edit != null) {
        edit.apply(doc);
        result = doc.get();
      }
      else {
        result = javaCode;
      }
    }
    catch (BadLocationException e) {
      throw new RuntimeException(e);
    }

    System.out.println(result);
  }
}

Step 3: there is no step 3! You can just run your code in your IDE or from the command line using maven to compute your classpath.

The code used in this example is a simplification of what you can find in another great open-source project: JBoss Forge Roaster.

Oxygen M4: convert to AsciiDoc with Mylyn WikiText

Wed, 21 Dec 2016 00:00:00 +0100

If you need to convert your documentation to the AsciiDoc format, you might be interested in this new feature delivered with Eclipse Oxygen M4 (see also my previous blog post: Asciidoctor instead of MediaWiki?). Any file format supported by Mylyn WikiText (textile, mediawiki, markdown and more) can now be converted to the AsciiDoc format. Just select WikiText ▸ Generate AsciiDoc from the context menu in the package explorer.

A new file is generated near to the original file (example.asciidoc in this example). Of course you can preview it with your favorite asciidoctor viewer (Chrome with the Asciidoctor.js Live Preview extension in my case).

While I was trying to convert some pages of Eclipsepedia to Asciidoctor, I have noticed that some additional concepts need to be supported by the converter. I have opened Bug 508262 to track them. Feel free to leave feedback there if something is not working for you.

You can get the Oxygen M4 version of Eclipse IDE from the Developer Builds download page.

Asciidoctor instead of MediaWiki?

Fri, 28 Oct 2016 00:00:00 +0200

During EclipseCon Europe 2016 we had a great BoF Session about documentation with Asciidoctor at Eclipse. A lot of subjects were discussed, from the editing possibilities inside or outside Eclipse IDE to the best toolchains for document generation/customization.

One topic that was discussed during the meeting was the conversion of MediaWiki documentation to the AsciiDoc format. I am happy to blog about this topic and to propose a solution.

A lot of Eclipse projects are using the Eclipse MediaWiki instance for their documentation. Maybe I can summarize my vision on this topic: I consider the usage of a Git repository better as a wiki engine. A wiki engine is not enough when it comes to documentation of different versions of your project/product (git branches, cherry pick…). If you host the repository on GitHub (it works also with GitLab) and if you use one of the markup syntaxes supported by the online editor, you get almost the same experience as with a wiki engine (online edition, online preview of changes, navigation in the history, diffs…). Reviews and discussions inside pull requests are a great way to collaborate. Having also everything offline is a big plus (I work a lot in the train). Amongst the different markup syntaxes you can choose, I consider the AsciiDoc format as the best option (management of code snippets, callout support in listings blocs, variable substitution and conditional inclusion, multiple output formats, live preview in browser during edition in any text editor, easy integration in existing build toolchain, possibility to extend the language with custom macros…). In my opinion Asciidoctor is becoming a state of the art documentation toolchain in many projects.

This immediately raises the next question: what can we do with the great content we have on the Eclipse wiki? How can it be migrated to the AsciiDoc format? In my opinion the Mylyn Wikitext project can help, but an AsciiDocDocumentBuilder is missing. I have opened Bug 506643 for that and contributed a first implementation. My code will now go through the eclipse review process. To test it today, you need to check out the repo (and the corresponding gerrit change).

Here a simple example:

Listing 1. Example MediaWiki document

'''Lorem ipsum''' sed tempor euismod elit, et eleifend tellus lacinia a.

=== Penatibus et magnis

Pellentesque ut ''lorem lorem''.

[[Image:foo.png|Foo image]]

Nulla ut sapien tellus. Quisque id semper nulla. Nullam facilisis risus turpis.

* Cras posuere tempor urna
* Laoreet pharetra diam rhoncus at
* Quisque ornare diam eu iaculis auctor.

Pellentesque tincidunt ultricies varius. [http://eclipse.org/ Lorem ipsum dolor] sit amet, consectetur adipiscing elit.

Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Suspendisse potenti.

That will be converted to:

Listing 2. Result of the conversion to AsciiDoc

*Lorem ipsum* sed tempor euismod elit, et eleifend tellus lacinia a.

=== Penatibus et magnis

Pellentesque ut _lorem lorem_.

image:foo.png[title="Foo image"]

Nulla ut sapien tellus. Quisque id semper nulla. Nullam facilisis risus turpis.

* Cras posuere tempor urna
* Laoreet pharetra diam rhoncus at
* Quisque ornare diam eu iaculis auctor.

Pellentesque tincidunt ultricies varius. link:http://eclipse.org/[Lorem ipsum dolor] sit amet, consectetur adipiscing elit.

Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Suspendisse potenti.

Of course my tool has certainly some limitations. Markup conversion is never an easy task. I think that the MediaWiki parser provided by the Mylyn Wikitext project is a good choice, because it is already used for the generation of some eclipse help pages. For the conversion to AsciiDoc there is already some support in the Wikitext framework (AsciiDoc is just an other output Markup there). I just created a new class: AsciiDocDocumentBuilder (plus an other one for the test suite). I have used the MarkdownDocumentBuilder as base and adapted it for AsciiDoc. I consider my implementation as a first usable version. Any feedback is welcomed (on the Bug, on Gerrit, twitter or on the mailing list). Depending on the feedback, I will be happy to iterate and to improve it for concrete use cases.

By the way, if an Eclipse Project wants to migrate and start to use Asciidoctor, I will be happy to help as much as I can.

EDIT: the feature is available in Eclipse IDE Oxygen version, read more here: Oxygen M4: convert to AsciiDoc with Mylyn WikiText.

Install "Plug-in Spy" in your Eclipse Neon IDE

Fri, 16 Sep 2016 00:00:00 +0200

There is a lot of documentation about the Eclipse "Plug-in Spy" feature (Plug-in Spy for UI parts or Eclipse 3.5 - Plug-in Spy and menus). Im my opinion one information is missing: what you need to install to use the Spy feature in your Eclipse Neon IDE. Here is my small how-to.

Select "Install new Software…" in the "Help" Menu. In the dialog, switch to the "The Eclipse Project Updates" update site (or enter its location http://download.eclipse.org/eclipse/updates/4.6). Filter with "PDE" and select the "Eclipse PDE Plug-in Developer Resources". Validate your choices with "Next" and "Finish", Eclipse will install the feature and ask for a Restart.

Figure 1. Install new Software in Eclipse

If you prefer the Oomph way, you can paste the snippet contained in Listing 1 in your installation.setup file (Open it with the Menu: Navigate ▸ Open Setup ▸ Installation).

<?xml version="1.0" encoding="UTF-8"?>
<setup.p2:P2Task
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:setup.p2="http://www.eclipse.org/oomph/setup/p2/1.0">
  <requirement
      name="org.eclipse.pde.source.feature.group"/>
  <repository
      url="http://download.eclipse.org/eclipse/updates/4.6"/>
</setup.p2:P2Task>

Your Oomph Editor should looks like in Figure 2. Save the file and select "Perform Setup Task…" (in the Help menu). Oomph will update your installation and will ask for a restart.

Figure 2. Oomph setup Editor: installation.setup File

In both cases, after the restart you can press alt+shift+f1 and use the Plug-in Spy as in Figure 3.

Figure 3. Plug-in Spy in Eclipse Neon

Eclipse Neon: diamond notation as clean-up action

Sat, 18 Jun 2016 00:00:00 +0200

I know Eclipse Neon brings features in the Java editor that I will use almost every day. I have already blogged about Bug 476304. It will be a pleasure to be able to navigate to inner classes correctly.

Today I want to write about the clean-Up to remove redundant type arguments feature. This is something I was looking for at the beginning of 2015.

Since Java 7 you can use the Diamond operator. The code line presented in Listing 1 (Java 6) can be written as in Listing 2 (Java 7).

Listing 1. Declaration and initialization of a List in Java 6

List<String> rows = new ArrayList<String>();

Listing 2. Usage of the diamond notation in Java 7

List<String> rows = new ArrayList<>();

With Eclipse Mars (and probably before) you could already let the compiler warn you about Redundant type arguments. The setting is under Preferences → Java → Compiler → Errors/Warnings in the tree. And in the list: Generic Types → Redundant type arguments (1.7 or higher) as presented in Figure 1.

Figure 1. Compiler setting for redundant type arguments

With this setting enabled, it was possible to Quick-Fix all the code locations that were not using the diamond operator (see Figure 2).

Figure 2. Quick-fix to remove redundant type arguments

This is a lot of CTRL+1 for an operation that does not require any manual intervention. If the team as decided to use the diamond notation, it should be used everywhere. This belongs to coding guidelines, exactly as code format.

With Eclipse Neon a new clean-up action makes this possible! You can configure Eclipse to remove redundant type arguments when you save your Java files. Open the preference page Java → Editor → Save actions. Check the Checkbox "Additional actions" and click on the Configure… button. Switch to the "Unecessary Code" Tab and enable "Remove redundant type arguments (1.7 or higher)"

Figure 3. Configure the new clean-up action with Eclipse Neon

Eclipse neon is coming next wednesday. Stay tuned!

Eclipse debugging: truncated String values

Fri, 27 May 2016 00:00:00 +0200

Being able to inspect variable values during debugging is probably one of the mostly used feature in Eclipse.

With String variables, the default Eclipse configuration is to truncate big Strings after 10000 characters. This can be a problem with long text documents loaded in a String.

Inspect a big String variable in Eclipse IDE

As always with Eclipse, there is a possibility to change this configuration. Just open the "Max Length…" entry in the context menu of the detail pane (Variables view). In the next dialog set the value "Maximum characters to display in details pane".

Open the 'Max Length…' entry in the context menu

The new limit will also be considered in the yellow overlay window.

Eclipse Neon: disable the theming

Sun, 24 Apr 2016 00:00:00 +0200

At Devoxx France 2016, Mikaël Barbero gave a great talk about the Eclipse IDE. The talks was well attended (the room was almost full). This is the proof that there is still a lot of interest for the Eclipse IDE.

The talk was a great presentation of all improvements made to the IDE (already implemented with mars, coming with neon or oxygen). It was a big new and noteworthy, organized by main categories that matters to the users and not by eclipse projects. I really appreciated this approach.

If understand French, I recommend you to watch the video of the talk. In the other case, I am sure you will learn something by just looking at the slides.

Something I have learned: with Neon you can deactivate the theming (appearance section of the preferences) completely. In that case the CSS styling engine will be deactivated and your Eclipse IDE will have a really raw look. To disable the theming, just uncheck the checkbox highlighted in Figure 2

Eclipse preferences > General > Appearance (Eclipse Neon)

After a restart your Eclipse will look like this screenshot (Figure 3):

Eclipse IDE with disabled theming

I hope the performances will be better, it particular when Eclipse IDE is used on distant virtualized environments like Citrix clients. If you want to test it now, download a Milestone release of Neon.

Documentation: do not forget the edit link

Fri, 22 Apr 2016 00:00:00 +0200

In my opinion if you publish documentation online, you should always tell your readers how they can change/update it.

I picked up several examples of documentation hosted on GitHub. On each page there is an "Edit on GitHub" link. This eases the creation of pull requests.

Example 1: Microsoft Azure documentation (see this page for example):

Example 2: the Eclipse Xtend documentation:

Example 3: Eclipse Scout documentation (see the scout "hello world" page):

Example 4: My blog (see my last article for example):

And many other projects are following this best practice…

This isn’t a GitHub only stuff. The same pattern can be used if the documentation is hosted on a wiki engine. As an example the GEF4 documentation does it exactly like that:

Asciidoctorj macro

If you are using asciidoctor for your documentation and if the sources are hosted on GitHub, you might be interested in the small extension I wrote: asciidoctorj-gh-edit. Short usage example:

:repository: jmini/jmini.github.io
:branch: develop

Do you want to improve this documentation? Please gh:edit[].

A second example where more parameters are defined as arguments of the macro:

See gh:view[repository='asciidoctor/asciidoctor.org', branch='master', path="news/debuter-avec-asciidoctor.adoc", link-text='this article in french'] on GitHub.

JBake blog

If you have a blog powered by JBake (like this one), you can add the code for the link creation in your templates. This way JBake generates the desired link on each page. I implemented it with some Groovy code included in the template. More details can be found on the JBake-user mailing list: Create a link "see blog post source on GitHub".

Use pull requests to improve documentation

Wed, 2 Mar 2016 00:00:00 +0100

Last November, I have presented a short introduction on Asciidoctor: Writing documentation with Asciidoctor (slides, video). As you can see in the video, several projects hosted by the Eclipse Fundation are already using Asciidoctor.

At the end of the presentation I discuss the fact, that you should always indicate to your readers how they can improve the document. In the latest version of the Eclipse Scout documentation (for example the Hello World Tutorial), I have included a link "edit on GitHub" at the bottom of each document:

Because I believe in this approach, even this blog has a "see source on GitHub" link at the bottom of each article.

The Pull Request model (it is the same for Gerrit changes) is really powerful tool to improve documentation. Each user can propose changes to the document, in order to improve it for all other readers. This is the exact same mechanism that makes Wikipedia the best encyclopedia of the world. Dan Allen uses this picture to illustrate this idea:

In the Eclipse Scout project, we have decided to use GitHub for our documentation, because they provide a really great interface to edit AsciiDoc text directly online. Even without having to check out the document, users can edit the text and get some preview of their changes. With one or two additional clicks they submit a pull request. With this kind of tools, the complexity of having a Git repository is removed. Users get something similar as online wiki engines, with one important addition: each change can be reviewed and discussed before it gets integrated into the final document.

By the way for closed source code, we are using a GitLab Backend on our company servers. We get a very similar user experience as with GitHub (see: Create files and directories from the Files page). The AsciiDoc editor is also great there.

A propos Asciidoctor, I will hold a Quickie Talk tomorrow (Thursday 03.03.2016) at Voxxed Day Zurich: Writing documentation with Asciidoctor. I hope I will meet other Asciidoctor users from Switzerland there.

Maven Repository and POM Files

Sun, 21 Feb 2016 00:00:00 +0100

This blog post is about Maven POM Files and publication of Eclipse jars in a maven repository. I use Mylyn-Wikitext as an example, because I know the project and I have worked on it. I think the same applies to other eclipse projects.

Mylyn-Wikitext is an eclipse project that provides great tooling for lightweight markup language (Markdown, MediaWiki, Textile, Confluence, TracWiki, and others). The project is spitted into several modules: some of them (like the Editor) are coupled to the Eclipse runtime but others (like the parser) can be used in plain java applications.

A simple Java Main Class (conversion from Markdown to HTML) is presented in Listing 1.

Listing 1. Simple Java Main Class using Mylyn Wikitext

import java.io.StringWriter;
import org.eclipse.mylyn.wikitext.core.parser.MarkupParser;
import org.eclipse.mylyn.wikitext.core.parser.builder.HtmlDocumentBuilder;
import org.eclipse.mylyn.wikitext.core.parser.markup.MarkupLanguage;
import org.eclipse.mylyn.wikitext.markdown.core.MarkdownLanguage;

public class MarkdownHelloWorld {

  public static void main(String[] args) {
    StringBuilder sb = new StringBuilder();
    sb.append("# Heading 1\n");
    sb.append("\n");
    sb.append("Hello World!\n");
    sb.append("\n");
    sb.append("* Lorem\n");
    sb.append("* Ipsum\n");
    sb.append("\n");
    sb.append("This is **Markdown**  language.\n");
    String text = sb.toString();

    MarkupLanguage markupLanguage = new MarkdownLanguage();

    StringWriter writer = new StringWriter();
    HtmlDocumentBuilder builder = new HtmlDocumentBuilder(writer);
    builder.setEmitAsDocument(false);
    MarkupParser parser = new MarkupParser(markupLanguage, builder);
    parser.parse(text);
    System.out.println(writer.toString());
  }
}

To build the code presented in Listing 1, you can use Maven with the pom.xml File presented in Listing 2.

Listing 2. POM File using a SNAPSHOT version from the Eclipse Maven repository

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company.example</groupId>
  <artifactId>helloworld-markdown</artifactId>
  <version>0.0.1-SNAPSHOT</version>

  <dependencies>
    <dependency>
      <groupId>org.eclipse.mylyn.docs</groupId>
      <artifactId>org.eclipse.mylyn.wikitext.markdown.core</artifactId>
      <version>2.6.0-SNAPSHOT</version>
    </dependency>
    <dependency>
      <groupId>org.eclipse.mylyn.docs</groupId>
      <artifactId>org.eclipse.mylyn.wikitext.core</artifactId>
      <version>2.6.0-SNAPSHOT</version>
    </dependency>
    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>[15.0.0,)</version>
    </dependency>
  </dependencies>

  <repositories>
    <repository>
      <id>eclipse.mylyn</id>
      <url>https://repo.eclipse.org/content/repositories/mylyn-snapshots/</url>
    </repository>
  </repositories>

</project>

This works and it is great.

Last year I have developed a simple maven plugin that generate the Eclipse Info Center XML file (e.g. toc.xml) for existing HTML pages. Of course it uses Mylyn Wikitext. In order to be able to publish a release of my plugin, I needed a maven repository containing a released version of Mylyn Wikitext and not a snapshot version.

I have used the Eclipse B3 tool to republish the Mylyn Wikitext jars coming from the Mars P2 Update Site to a maven repository hosted on Bintray. I my opinion this was a workaround until Bug 421551 is solved (see Bug 421551: publish current stable release to a Maven repository). The B3 XML file is published on GitHub.

Last week I discovered something interesting. With my maven repository, the POM file to build the simple Hello World from Listing 1 is much simpler and is presented in Listing 3.

Listing 3. POM File using a released version from my Bintray Maven repository

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company.example</groupId>
  <artifactId>helloworld-markdown</artifactId>
  <version>0.0.1-SNAPSHOT</version>

  <dependencies>
    <dependency>
      <groupId>org.eclipse.mylyn.docs</groupId>
      <artifactId>org.eclipse.mylyn.wikitext.markdown.core</artifactId>
      <version>2.6.0.v20150901-2143</version>
    </dependency>
  </dependencies>

  <repositories>
    <repository>
      <id>bintray.jmini.maven</id>
      <url>http://dl.bintray.com/jmini/maven/</url>
    </repository>
  </repositories>

</project>

The reason is simple. The pom files are not the same:

The pom file describing org.eclipse.mylyn.docs:org.eclipse.mylyn.wikitext.markdown.core:2.6.0-SNAPSHOT in the Eclipse Maven Repo is the pom uploaded by the maven-tycho build (packaging is eclipse-plugin, there is no <dependencies> section).
The pom file describing org.eclipse.mylyn.docs:org.eclipse.mylyn.wikitext.markdown.core:2.6.0.v20150901-2143 in my Maven repository is generated by the Eclipse B3 tool (default packaging, has a <dependencies> section)

Eclipse B3 uses the Installable Unit of the P2 update site as input. The POM file is not present and has to be generated. The big difference is the dependencies section. My guess is that they have been derived by B3 from the P2 Metadata. The resulting POM is much user friendly for the developers that want to consume the library from the maven repository.

I am not a maven expert. Did I miss something?

I see more and more projects pushing their library to maven central. This is really nice. Tom Schindl has explained in a Blog Post that he was manually (re)publishing some components of the Eclipse Platform to Maven Central (com.ibm.icu.base, org.eclipse.e4.core.di.annotations, org.eclipse.equinox.common, org.eclipse.jdt.annotation, org.eclipse.text …). My feeling is that we have with Eclipse B3 a great piece of technology that can be used to (re)publish some of the content of the simultaneous release train on maven central. If there is enough interest, a maven job using Eclipse B3 could be prepared to push a fixed list of libraries on a maven repo (the eclipse one or even better maven central).

Terminate and Relaunch in Eclipse IDE

Fri, 12 Feb 2016 00:00:00 +0100

Are you using the "Terminate and Relaunch" context menu in the Debug view?

Last year Martin Lippert did a demo of the "Spring Tool Suite" at the Eclipse Demo Camp in Zurich. He presented a great addition to the Eclipse Toolbar: the possibility to terminate and relaunch an application from anywhere.

We discussed after his presentation if this feature could be integrated in Eclipse IDE. I think it would be great and I imagine I would use it every day (now I am switching to the Debug perspective to do it). I have opened Bug 487554 for that. Feel free to share your opinion there.

Bug 75981 is fixed!

Sat, 6 Feb 2016 00:00:00 +0100

Like many of my Eclipse stories, it starts during a coffee break.

Have you seen the new TODO template I have configured for our project?
Yes. It is nice…

But I hate having to set the date manually.
I know but it is not possible with Eclipse.
…

A quick search on Google pointed me to Bug 75981. I was not the only one looking for a solution to this issue:

By analyzing the Bugzilla history I have noticed that already 2 contributors have started to work on this (a long time ago) and the feedback to the latest patch never got any answers. I reworked the last proposal… and…

I am happy tell you that you can now do the following:

Short description of the possibilities:

As before you can use the date variable with no argument. Example: ${date}
You can use the variable with additional arguments. In this case you will need to name the variable (since you are not reusing the date somewhere else, the name of the variable doesn’t matter). Example: ${mydate:date}
- The first parameter is the date format. Example: ${d:date('yyyy-MM-dd')}
- The second parameter is the locale. Example: ${maDate:date('EEEE dd MMMM yyyy HH:mm:ss Z', 'fr')}

Back to our use case, it now works as expected:

Do not hesitate to try the feature and to report any issue you can find. The fix is implemented with the M5 milestone release of Eclipse Neon. You can download this version now here:

http://www.eclipse.org/downloads/index-developer.php

This experiment was also a great opportunity for me to measure how the development process at Eclipse has been improved:

With Eclipse Oomph (a.k.a Eclipse Installer) it is possible setup the Workspace to work on "Platform Text" very quickly
With Gerrit it is much easier for me (a simple contributor) to work with the commiters of the project (propose a patch, discuss each line, push a new version, rebase on top of HEAD…)
With the Maven Build, the build is reproducible (I never tried to build the platform with the old PDE Build, but I believe that this was not possible for somebody like me)

Where I spend most of the time:

Analysis of the proposed patches and existing feedbacks in Bugzilla
Figure out how I could add some unit tests (for the existing behaviour and for the new use cases).

This was a great experience for me and I am really happy to have contributed this fix.

A Desktop Wallpaper inspired by the Eclipse Logo

Sun, 3 Jan 2016 00:00:00 +0100

Few months after the release of the new Eclipse Logo, I created this wallpaper for my Desktop:

I finally took the time to share it with the eclipse community.

It was created by transforming this Flickr photo by Abel Pardo Lopez. Like the original file, it is distributed under a Creative Commons Attribution 2.0 Generic License. You can download it from my bintray repository: EcDeWa.zip

Migration to JBake

Sun, 27 Dec 2015 00:00:00 +0100

I have changed the technology stack for this blog.

This blog was hosted and built on GitHub pages (key technologies: Jekyll and Markdown).

I have moved to:

Blog posts written in AsciiDoc
JBake (which uses Asciidoctor)
Maven for the build
GitHub pages to host the output

If you are interested by this setup, have a look at this example project: jbake-sample

My motivations are:

Now that I am using Asciidoctor a lot, I really prefer writing my blog posts in the AsciiDoc format.
I like to be able to work offline (my use case is "working in the train"). With this setup I can preview the output on my machine before I push the commit to GitHub.
RSS/Atom feed is requested for the Eclipse Planet (I cannot use HubPress for this reason).
I still use GitHub to host the sources (because I believe in the pull request model) and to host the final result (hosting on GitHub.io is great).

Next steps:

Continuous integration with Travis CI
Change/improve the Blog theme

Backing the next version of JUnit

Mon, 17 Aug 2015 00:00:00 +0200

Some developers have started a crowdfunding campaign to trigger the development of the next version of JUnit.

On Voxxed: JUnit Lambda: The Future of Testing on the JVM Gets Crowdfunded
On JAXenter: Crowdfunding for JUnit Lambda is underway

Because I believe the JUnit library needs to evolve, I have participated in the fundraising campaign.

EclipseCon participation and return on investment

Mon, 10 Nov 2014 00:00:00 +0100

2 weeks ago, I had the chance to participate to the EclipseCon Europe 2014 and enjoyed it. On the way back, I was asking myself why I found it so great.

Of course, like in every conference, you have a lot of talks proposed on parallel tracks. You can pick the topics that are interesting for you and make your own program. Talks are a good way to discover a new trend, a new feature, a new tool…

The keynotes are also great. For me it is always a great source of inspiration. They are a way to discover new ideas or new approach. Sometime there is nothing new in the talk but the presentation and or the speaker make the difference. A keynote is good if I can think of the message days or months later.

I have tried to check is the investment (time, money - for you and / or your company) was justified or not. In my opinion it is all about what you have learned during those days. New tools or trends are important, but solving the real problems you have in your project is what will make a difference.

My experiment

This summer I have started to evaluate the web-IDE Orion to contribute something in the Eclipse Scout git repository using gerrit. I wasn’t very successful (see this forum thread: push a commit to gerrit). I decided to stop the experiment and not to invest much time in the evaluation. I never worked on this task again.

On Wednesday, when I was at the EclipseCon, it hit me: one or more attendants of the EclipseCon had probably the information I needed in order to push my commit to Gerrit. I started to ask around (IBM booth, staff of the eclipse foundation) and everybody told me I should speak to John Arthorne. I needed to find him and I started to ask around. To maximize my chances, I started to misuse the monitor at the eclipse scout booth during the evening (Club ECE).

We also used Twitter to broadcast the information.

Suddenly Olivier Prouvost told me: "Hey, John is right here". This is the EclipseCon magic!

John helped me with my problems and we managed to push my commit from Orion to Gerrit.

Published on twitter. Photo credit: Matthias Zimmermann

Helping others

I think this mechanic is important and can justify for people to come to the EclipseCon. At the Eclipse Scout booth, we always welcome people coming with a laptop and their questions about our framework. We always manage to find the time to do some pair-programming at our booth. It is a kind of "1:1 training" for free.

If you plan to attend to an EclipseCon, you should prepare a list of questions or of problems you want to solve during the conference. Finding people is not complicated: attend to a talk on the topic, identify the speaker and talk to him later. Visit a booth. Start to ask around. Everybody will be happy to help you. You will discover what being part of the Eclipse community means.

Let be part of it

Sat, 1 Nov 2014 00:00:00 +0100

I really appreciate to read blogs from all over the world… I think this is an incredible way to learn from others and to share knowledge.

I have opened this blog to be part of it. I see it as a way to share knowledge and to write about my ideas.

I have hosted this blog on GitHub. Maybe someone will send me some pull requests to improve the content (update broken links, fix typo, rephrase the text). Feel free to use the issue tracker to suggest new topic or to start a discussion.